Electronic bill payment with variable payment options

ABSTRACT

A system for bill payment services includes a computer system for accessing biller data, the biller data comprising at least an account identifier, an amount due, and a nominal bill due date. A payment option generator is configured for developing at least one payment option, where a payment is specified responsive to a difference between a proposed payment date and the nominal bill due date. A payer interface is configured for presenting the payment option to the payer, and for accepting a payer option selection and payment funding confirmation. A payment execution controller is responsive to the payer option selection and funding confirmation, for initiating payment to a biller account on behalf of the payer.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/295,012, filed Jun. 3, 2014, which is a continuation of U.S.application Ser. No. 12/191,112, filed Aug. 13, 2008, issued on Jun. 3,2014 as U.S. Pat. No. 8,744,959; each of which are incorporated byreference herein, in their entireties.

BACKGROUND OF THE INVENTION

The present invention relates to a system and method for bill payment.More specifically, the present invention relates to a system and methodfor bill payment with variable payment options.

It is increasingly common for funds to be transferred electronically.This can occur from individual to individual, from business to business,or between an individual and a business. The transfers may occur withinone country or across borders, and thus may involve a currency change.

In some money transfer systems initiated by individuals, such transfersmay be handled as one-time transactions funded with cash. In some casesthis is because the individual sending the funds lacks an account at abank or a credit card. Thus, the funds for each transfer are provided incash (or equivalent), paid separately before each transaction. Non-bankfinancial institutions perform such transfers for persons who are“unbanked”.

In the context of transfers from an individual to a business or businessto business, funds may be electronically transferred in response to abill issued and outstanding, such that the payer uses a money transferto effect bill payment on a bill due to the business. Non-bank financialinstitutions with money transfer systems may perform bill payment forpersons who are “unbanked”.

BRIEF SUMMARY OF THE INVENTION

A system for third party bill payment services used by a payer to pay abiller with whom a payer has an account is provided. The systemcomprises: a third party computer system for accessing biller data, thebiller data for the payer comprising at least one account identifier, anamount due, and a nominal bill due date; a payment option generator fordeveloping at least one payment option wherein the payment specified isresponsive to a difference between a proposed payment date and thenominal bill due date; a payer interface for presenting the at least onepayment option to the payer and for accepting a payer option selectionand a payment funding confirmation; and a payment execution controllerresponsive to the payer option selection and funding confirmation, forinitiating payment to a biller account on behalf of the payer.

In another embodiment, a method for third party bill payment services isprovided. The method is used by a payer to pay a biller with whom apayer has an account and comprises: receiving from a payer at a thirdparty computer system information including at least a billeridentification, a proposed payment amount, a proposed payment date, anda nominal bill due date; verifying at least a portion of the receivedinformation against payer account records; calculating a differencebetween the proposed payment date and the nominal bill due date; andgenerating and presenting to the payer at least one payment option inwhich the payment required is responsive to the calculated differenceand stored payment option rules for the biller.

In yet a further embodiment, a computer readable medium encoded withcomputer program instructions for performing third party bill paymentservices is provided. The computer readable medium is encoded withcomputer program instructions for a third party computer system forperforming third party bill payment services to pay a biller with whom apayer has an account, comprising: an instruction module for accessingbiller data, the biller data for the payer comprising at least oneaccount identifier, an amount due, and a nominal bill due date; aninstruction module for a payment option generator for developing atleast one payment option wherein the payment specified is responsive toa difference between a proposed payment date and the nominal bill duedate; an instruction module for a payer interface for presenting the atleast one payment option to the payer and for accepting a payer optionselection and a payment funding confirmation; and an instruction modulefor a payment execution controller responsive to the payer optionselection and funding confirmation, for initiating payment to a billeraccount on behalf of the payer.

While multiple embodiments are disclosed, still other embodiments of thepresent invention will become apparent to those skilled in the art fromthe following detailed description, which shows and describesillustrative embodiments of the invention. As will be realized, theinvention is capable of modifications in various aspects, all withoutdeparting from the spirit and scope of the present invention.Accordingly, the drawings and detailed description are to be regarded asillustrative in nature and not restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram of a system for performing thirdparty bill payment transactions in accordance with one embodiment.

FIG. 2 is a table showing biller data types in accordance with oneembodiment.

FIG. 3 is an example of a time-line showing various payment windows.

FIG. 4A is a table showing a hypothetical example of payment windows andassociated payment option data.

FIG. 4B is a table showing an alternate hypothetical example of paymentwindows and associated payment option data.

FIGS. 5A, 5B, and 5C are a flowchart showing one embodiment of a billpayment method.

FIG. 6 is a data diagram showing an example of a biller data record fora customer who may become a payer using the present system.

FIG. 7 is a schematic screen layout for a screen of the biller accountmanagement portal.

DETAILED DESCRIPTION Introduction

A computer-implemented method and system for bill payment with variablepayment options is provided.

A financial institution (FI) (bank or non-bank) may have systems formaking certain money transfers. FIs may offer, as part of a moneytransfer system, bill payment to specific billers with whom the FI has arelationship. A non-bank FI (NBFI) may have well-developed moneytransfer systems and methods effective for money transfer by personsthat do not have conventional checking or other payment accounts. Suchsystems and methods may be suitable also for a payment transactionwhereby a payer may send money to pay a biller account for that payer.In some embodiments, the biller may be one of a list of billers thathave developed a payment processing arrangement with the NBFI. Suchbillers may be utilities, car purchase financing organizations and thelike. For example, Jane Doe may wish to make a payment on her accountwith the electrical utility using an NBFI, because she has no bankingrelationship. This class of system may be referred to as a third partybill payment system. The NBFI acts as a third party between the payerand the biller to facilitate payment, when the payer cannot or does notwish to make the payment by check, money order or delivery of anotherpayment instrument to the biller. Conventional FIs also may offer suchthird party payment services to customers. In the following, we willrefer primarily to FIs, which will be deemed to mean either conventionalFIs or NBFIs, in each case using the methods and systems described.

The FI expects to be paid for its role in the payment transaction. Thus,the bill payer may be required to pay a total amount that includes a feein addition to the billed amount paid to the biller. Alternatively, thepayer pays all or a portion of the amount due, and the biller and the FIhave an agreed arrangement as to the FI's fee to be taken from thatpayment or from some aggregate group of payments. Thus, in the past, thepayer usually has only one option offered to him/her: a billed paymentamount plus a transaction fee, or a billed payment amount with novisible, separate transaction fee.

An FI may increase the value of its services and attract more billersand payers with an expanded set of bill payment options. The system andmethod described below permit the FI to collaborate with the biller tooffer bill payment options that let the biller adapt the payment optionsto the circumstances of the payers and also to the circumstances of thebiller.

The starting point for such a bill payment system is that the biller haselectronic account records covering the payers that biller has billedand that might make a payment through the present third party paymentservice (e.g., customer accounts for the customers of a utility, aretail store chain or an automobile seller who provides financing, withpayments due at intervals). Such records state for each payer account abilled amount and the nominal bill due date for paying that amount (butmay contain other information about the payer account), and can be madeavailable electronically to the FI/third party payment service. Therecords available to the FI may be the same as the records the billeruses for its billing (e.g., by mailed bills) and may be electronicallyshareable with the FI providing payment services. Electronic sharingpermits the FI/third party payment service provider to have available,up-to-date amount and due date information for payers that use itssystem. It may be desirable for the FI to have access to the accountrecords of potential payers as stored by the biller on the biller'ssystems or for the FI to store a copy of relevant portions of theserecords. The FI, as third party provider of bill payment services, usesits FI central/third party computer system to access payer accountrecords when a payer wishes to use the FI's third party paymentservices. As will be described, the data in these records may be used todevelop and present to a payer at least one payment option from variablepayment options defined within the FI's bill payment system.

The variable payment options themselves are defined in one of more setsof biller payment option rules. With the present system and method, thebiller and/or FI define payment option rules that fit the biller'sapproach for collecting its accounts receivable and accommodate the FI'sneed for payment for its services. The rules must be compatible with theFI's facilities for interacting with customers and must also beconsistent with any applicable regulatory schemes for consumer creditand debt collection and the like. In a data processing system ofsuitable speed and capacity, appropriate payment option rules of manykinds may be programmed and implemented as software modules and/or datastructures in the FI's data processing systems. In one embodiment, thepayment rules are based on a time-line that includes dates preceding thenominal bill due date and extending for some time after it. That is, thepayment option rule applicable may vary according to where on thetime-line the payer makes the payment. For example, a biller may have aset of payment option rules that compare the payer's actual or proposedpayment date using the FI payment service to the payer's nominal (i.e.,previously notified) bill due date, to develop and select among possiblepayment options and then cause the system to present one or more ofthese options to a payer who contacts the FI seeking to make billpayment through it. The rules may define a number of different paymentwindows, corresponding to different time intervals associated withdifferent payment options, before, including and after the nominal billdue date.

In another embodiment, the biller and/or FI can reference data otherthan the nominal bill due date and amount due as part of applying theoption rules to define or select payment options to offer the payer. Forexample, the biller may wish to consider historical billing and paymentrecords for a particular payer (customer) as part of determining thepayment options to be offered. The biller also may wish to vary thepayment option rules and resulting options by season, e.g., with morefavorable fees or interest rates for post-holiday billed amounts or tocoincide with payers receiving tax rebates. The rules for developingpayment options may be developed in a collaboration by the FI andbiller. Depending on who has the greater experience or customer insight,the FI may propose the payment option rules that are most effective andimplementable within its system. Alternatively, the biller may have adesire to shape the rules to fits its policies toward its customers.

Application of the payment option rules may result in a payment optioninvolving a single, undifferentiated payment amount, responsive to thepayment amount due on the biller's account records for a particularpayer. Alternatively, the payment option rules may result in a paymentoption that states a payment amount and a separate fee component.Further alternatively, the payment option rules may result in a paymentoption that states a payment amount, a separate fee component based onuse of the FI/third party payment system and one or more othercomponents, such as a late charge, additional interest, or other amount.

The payment option may most often vary based on the date of paymentrelative to the nominal due date of the bill. With varying paymentoptions and multiple payment options available in some circumstances, abiller and/or FI may incent a payer to pay early but may still offer theoption of paying later. Thus, a payer may choose between speed ofpayment posting and cost of transaction. Additionally, a biller mayprovide different payment options by allowing convenience payments aswell as urgent payments (likely higher-priced), e.g., where repossessionor other extreme consequences might follow failure to pay.

In addition to the biller payment option rules, the FI and biller mayagree on, and the FI system implement, biller-FI fee and settlementrules. The fee paid to the FI may be the same as a separate feecomponent identified in a payment option. However, the FI's fee also maybe a portion of the fee quoted to the payer or that fee plus anadditional amount taken from the principal billed amount. The fee to theFI may consist of a single fee per payment transaction or it may havetwo or more components. The separate components may or may not be madevisible to a payer. For example, a fee may be charged by the FI forperforming the money transfer (the “transfer fee”) and a fee may becharged by the biller for receiving the bill payment via this channel orat a late date (the “biller fee”). This can be shown as two separatefees or a single fee amount.

In addition, the FI and the biller may have a fee arrangement betweenthemselves, which is not connected to individual payments but rather toan aggregate amount of payments over a time period, and it may vary bythe size of the aggregate amount. (For example, the FI might get a 1%fee on the first $1 million in payments, and 0.8% of the paymentsthereafter.) Various sharing formulae and rate schedules may be appliedto amounts the FI collects for a biller and used to determine the FI'sfees; these biller-FI fee and settlement rules may be implemented assoftware modules or data structures in the system.

The biller-FI fees earned will be tracked in accordance with theapplicable rules for individual transactions or for whatevertransactions are aggregated for a fee computation per the fee andsettlement rules. At intervals, the biller and the FI will effectsettlement as to amounts paid by payers and applicable fees for suchpayments. Thus, fee and settlement rules may also define when and howfunds actually are transferred to a biller bank account or an FIaccount, e.g., daily or weekly transfer by ACH, by wire transfer or bymailed check, to effect settlements over a defined period.

Payment Processes Overview

Bill payment through a conventional NBFI system may comprise two phasesfrom a payer and NBFI viewpoint: (1) staging, during which parametersare set for the payment, based on one or more payment options offered,but no funds are exchanged, and (2) fulfillment, during which the payerfunds the transaction to the NBFI (or its agent) and the NBFI takes thedesired action to credit a biller account. (See, e.g., U.S. Pat. No.7,258,268, titled “Method and Apparatus For Money Transfer). Thus, inpractice, after specifying the bill payment transaction parameters andcreating a record in an NBFI data center (staging), for fulfillment thepayer makes a cash or other payment to cover the amount paid plus anyfees, permitting the NBFI to execute a transfer to the biller. As may beappreciated, amounts for any fee the payer must pay may be determined atthe staging phase. It is desirable that the fee amount remains the samefrom staging to fulfillment, but it may be changed; for example, if acertain amount of time elapses between staging and fulfillment, apayment option staged based on a current date or proposed payment datewith an associated fee may no longer be available.

Bill payment may also be done in a single session where staging andfulfillment phases occur together. This can be done where the payer ispresent at an agent or point of sale, which can do both staging andreceive fulfillment funds. It can also occur in other circumstanceswhere the staging payer has a non-cash source of funds that can beapplied at the same time the transaction is being staged. Such anon-cash source of funds may be a debit card, a credit card, an on-lineaccount or other funding facility that can be accessed at the same timeas the other parameters of the bill payment transaction are establishedand entered as a record in the NBFI data center.

Execution of the payment by money transfer to the biller occurs afterthe FI has secured funds or has an acceptable level of risk of paymentthat it is willing to advance funds. In execution the biller first willbe notified of payment, so that it may stop unnecessary payment noticesto the payer (debtor). Preferably, the FI computer system notifies thebiller of the payer's payment at a time substantially commensurate withthe FI receiving payment from the payer. The biller will receive acredit in its account with the FI and at a point determined by the feeand settlement rules will have funds transferred to a biller bankaccount. (To the extent an FI agent has been involved in receiving thepayer's fulfillment payment, the FI must make arrangements to collectthose funds and to pay the agent its fees for handling the fulfillment;these arrangements are normally not part of the biller-FI fee andsettlement rules.) Thus, the payer's funding of the bill payment may befollowed by various reconciliation and/or settlement actions executedbetween the FI and biller pursuant to the fee and settlement rulesand/or between the FI and its agents.

System Elements and Operation

FIG. 1 is a schematic block diagram of a system 100 for performing moneytransfer transactions for bill payment with variable payment options. Asshown, one or more payers 10 may stage a send transaction to make apayment to a biller 24 (represented in FIG. 1 by Biller A, Biller B, . .. Biller N) using one or more payer interfaces 12 provided by the FI asa third party bill payment service provider. A payer interface 12 mayreceive via staging module 12 a the parameters of the desired billpayment and communicates, directly or indirectly, with a central dataprocessor 14 with a payment option generator 16, an execution controller17 and a general application controller 21. The central data processor14 (third party computer system) accesses storage/database 18 with:biller data 32, including Payer Account Records 34 (e.g., payeridentifiers, amounts due, and nominal bill due dates); payment optionrules 36; and fee and settlement rules 38. The central data processor 14and payment option generator 16 stage the transaction based on paymentoptions presented at the payer interface 12 and information input by thepayer 10, described more fully below, and by using the payment optionrules 36 of the particular biller who is to be paid; i.e., each billermay have its own payment rules, although an FI also could have one setof rules for all billers or for each class of billers (utilities,retail, gas stations, etc.). A payment staging record for each stagedpayment is produced by the central data processor 14 and stored withpayment records 39. Staged payment records 39 are updated whenfulfillment occurs, and payment records 39 may be further updated whenfunds received by the FI are processed in reconciliation and settlement.

A biller account management portal 22 may be provided for billers 24 tointeract with a biller account manager 40 component via the FI CentralData Processor 14. The interaction of the biller account managementportal 22 and the biller account manager 40 may be configured in asoftware module so as to allow a biller 24 to select the application ofalternative sets of payment rules 36. In some circumstance the biller 24may use the biller account management portal 22 to adjust certainparameters embodied in the payment rules 36, within ranges previouslyagreed between biller and FI and implemented in biller account managersoftware 40. In some embodiments, a real time communication link 20 maybe provided between the central data processor 14 and the biller accountmanagement portal 22, as the path for communications that ultimatelyinvolve the data and software modules in storage/database 18 and on thebiller computer systems (FIG. 1 at 24, Acct Sys). The biller accountmanagement portal 22 may link to each biller's 24 own accounting system(represented in FIG. 1 at 24 by Acct Sys 1, Acct Sys 2, . . . Acct SysN), where it keeps billing records. These are the ultimate source of thePayer Account Records 34 in storage/database 18. (It will be understoodthat storage/database 18 might not locally store Payer Account Records34 but rather access data as needed in one of Acct Sys 1, Acct Sys 2, .. . Acct Sys. N or may have a local copy of some Payer Account Records34 and for updating may check the Acct Sys of a particular biller.)

When bill payment is performed in two stages, after the payer 10 stagesthe transaction, the payer 10 makes a payment through a secondinteraction at a payer interface controlled by fulfillment module 12 b.The payer interface with fulfillment module 12 b may be one of the otherpayer interfaces 112, i.e., a location different than the payerinterface 12 used for staging. The payer interface 12 (or 112) used forfulfillment is controlled and defined by fulfillment module 12 b, whichreceives payment funding confirmation and communicates, directly orindirectly, with the central data processor 14.

Confirmed payment at the fulfillment payer interface 12 (or 112)initiates execution of the bill payment transaction. Payment actions aredirected by execution controller 17, which is a controller responsive toa payer's payment option selection and funding confirmation, forinitiating payment to an account of the biller 24 that is to be paid bythe staged and now fulfilled transaction. The payment amount, includingany separate fees (which may result from fee arrangements agreed to bythe specific biller 24 (identified by the payer 10 during staging) andthe FI), is first placed in a payer payment account 62 (managed by anagent or a pooled account managed by the FI) and may then credited to abiller holding account 64 (a bookkeeping account of the FI in FIaccounts 60) and, typically, later transferred to a bank account 26controlled by the biller 24 who was paid. The bill payment amount,payer/account identification and associated bill payment data as storedin payment records 39 for a completed payment transaction may be eithermade accessible to biller fee management portal 22 or transmitted on tothe accounting systems of biller 24, to permit the biller 24 to creditthe payment to the proper payer account within its own records.

General application controller 21 performs control and coordination forfunctions and system services not handled by payment option generator 16and execution controller 17. For example, it may perform functions suchas transaction queuing, between-module communications and communicationsbetween the central data processor 14 and other external parts of thesystem.

In various embodiments, either of the staging and fulfillment payerinterfaces 12 and 112 may be based in a phone (Interactive VoiceResponse—IVR or live customer service representative), a computerinteracting via the web (or other communication channel), a mobileplatform such as mobile e-mail unit or mobile phone, or other interfacefor allowing payer interaction with the central data processor 14. It isto be appreciated that the method and system described herein may beapplied to any suitable payer interface 12 that will support a datainterchange for staging and fulfilling a payment transaction of the kindcontemplated with a reasonable degree of security. A payer interfaceused for staging only has staging module 12 a to develop and displaypayment options and structure and control the staging interaction; apayer interface used for fulfillment only has fulfillment module 12 b tostructure and control the fulfillment interaction; some payer interfaces12, 112 may have both modules 12 a, 12 b.

FIG. 2 is a table that shows at a high level the organization of some ofthe data in database/storage 18, in particular what may be included inbiller data 32. (It will be understood that the data 31 may be organizedin any suitable manner available with a conventional data basemanagement system; thus, “data” may include a pointer or some othermeans of linking to actual data.) In column 210 appear the names,identification and/or biller numbers and/or other identifiers/data forone or more billers who have a relationship with the FI. In column 220is shown the general format for payer account records 34 (see FIG. 1).For each biller in FIG. 2, there is a separate set of records 34A, 34B,. . . 34N. Each biller's records may show its multiple payers, e.g.,PayerA1, PayerA2 . . . Payer An, and have various fields that identifyeach payer by account number with that biller, by name and address or bytelephone number or other identification (see FIG. 6 below). (Forprivacy reasons, only an account number might be used here.)

In column 230 are the payment option rules 36A, 36B, . . . 36N for eachbiller. These payment option rules 36A, 36B, . . . 36N may include oneor more sets of rules that may be defined in software or data structuresand adopted from time to time to define the variable payment options. Incolumn 240 are biller-FI fee and settlement rules 38A, 38B, . . . 38N,which define the fee arrangement and settlement procedures(timing/frequency, payment method, accounts used) between the biller andthe FI. In column 250 are biller payment records 39A, 39B, . . . 39N,which keep track of staged payments and actual fulfilled payments thatresult in credits to the biller to whom the payer directed payment.Although shown here as sorted by biller, these may actually be organizedby payment transfer transaction identifiers used by the FI. A storedfile pooling such transactions, e.g., payment records 39 in FIG. 1, maybe linked to by biller ID.

Biller Payment Option Rules

Biller payment option rules 36A, 36B, . . . 36N are used in the system100 to define, for a particular payer and payment situation, at leastone payment option from a set of payment options. The present system hasvariable payment options, differing in amount according to one or morevariables. In a prior art system, there might be a single paymentapproach the FI uses for its third party bill payment services; forexample, the payer pays the amount shown as due per biller records plusa fixed fee of $2.00. The FI could use an alternate approach reflectingthat an electronic payment using the FI system may cost a biller less toprocess in than a mailed check. Here, the FI could offer that, for atimely payment (not overdue), the payer pay only the amount due perbiller records, with no additional fee. With a set ofcomputer-implemented payment option rules as permitted by the presentsystem and method, the biller and the FI may offer different paymentoptions to payers in different situations.

The amount and structure of the payment defined in a payment option maybe varied based on a variety of data reflected in the payer accountrecords. The data considered may include, for example, the nominal duedate of the bill payment relative to a proposed (staged) or actual(fulfilled) payment date using the FI/third party service, includingwhether the payment is comfortably in advance of the due date, veryclose to the due date or wholly or partially overdue. For payments thatare overdue, the biller may wish to have late fees or interest chargesbuilt into the payment or may choose to suggest clearing up an accountwith a payment for less than an amount previously billed as due. Thelatter can be done by waiving late fees or interest charges and/or bygranting an accommodation that represents a discount on the base billedamount (or principal amount) without any late fees or interest charges.For payments that occur well in advance of a nominal due date, an earlypayment with a discount might be defined in a payment option. If thepayer is staging a payment comfortably in advance of a nominal bill duedate, the FI system may offer two payment options, a base amount plus anominal fee for an early payment or a base amount plus a higher fee fora payment that is made very close to the due date. All of these paymentoptions and others can be defined in payment rules 36A, 36B, . . . 36Nimplemented in software modules and or data structures. (As discussedfurther below, associated with each of these sets of payment optionrules for a biller are biller-FI fee and settlement rules, but the feeto the FI need not be identical to any fee stated in a payment optionoffer to the payer.)

In one embodiment, a primary factor in defining bill payment options isthe date of payment via the FI relative to the nominal bill due date,i.e., the difference (positive or negative) between the date of paymentusing the FI and the nominal bill due date per biller records. In oneembodiment, bill payments may generally fall under three broadcategories: convenience payments, urgent payments, and late payments.Convenience payments may comprise early payments and on-time payments.An early payment may refer to a payment made some period of time wellbefore the payment due date. In some embodiments, an early payment is apayment made ten to thirty days before the payment is nominally due. Anon-time payment may refer to a payment made before the payment is duebut outside of the range allotted to early payments. In someembodiments, an on-time payment is a payment made two to nine daysbefore the payment due date. Urgent payments refer to payments madeproximate the payment due date. In some embodiments of payment optionrules, an urgent payment is a payment one day prior to or on the day ofthe nominal bill due date.

Late payments refer to payments made after the payment due date. In someembodiments of payment option rules, late payments may be categorizedaccording to days past due, such as one day past due, five days pastdue, ten days past due, thirty days past due, sixty days past due,ninety days past due, one hundred and twenty days past due, etc. It willbe seen that the categories are flexible and may be selected by thebiller and/or the FI based on their billing practices. They may also bedetermined based on laws and regulations about consumer billingpractices. The different time intervals representing conveniencepayments, urgent payments, and late payments may be viewed as paymentwindows along a time-line. The different windows open and close as thedue date approaches and passes and as late payments get later.

One way of viewing the payment option rules based on due dates is interms of a predetermined set of payment windows with correspondingpayment option definitions. FIG. 3 shows a set of payment windows thatmay be defined for payment option rules in a third party bill paymentsystem. As can be seen, the time-line 310 of days may include thenominal bill due date 302, a sequence of days 304 preceding the due dateand a sequence of days 306 following the due date 302 (indicated byminus signs preceding the numbers). Various segments of the sequences ofdays may be identified by somewhat arbitrary window labels, associatedwith the payment option definitions. For example, a first set of labelsappears in row 320 below the time-line 310 of days. These window labelsinclude: early payment, on-time payment, urgent payment, excused latepayment, late over 5 days payment, late over 30 days payment, late over60 days payment, late over 90 days payment, and late over 120 dayspayment. A second and a third set of window labels appears in rows 330and 340 of FIG. 4, respectively, further below the time-line 310 ofdays. The second and third sets of labels are somewhat simpler than thefirst set 320, but still contain multiple windows and thus also providea basis for varying the payment options, one or more of which can bepresented to a payer who is planning a payment. As can be seen, whilethese window labels in window sets 320, 330, 340 are rigorously definedfor purposes of a specific implementation of the payment rules 36A, 36B,. . . 36N and other data processing, the categories are flexible andpermit virtually any definition, (unless determined by law orregulation). This permits the biller and FI to define a variety ofpayment windows with which payment options may be associated.

FIG. 4A shows a hypothetical set of payment option rules 400 a for abiller, e.g., BillerA in FIG. 2, that may be set up based on the paymentwindows in the first row 320 below the timeline in FIG. 3. These paymentoption rules define various payment options, each corresponding to apayment window. They also show the way a payment made within any of thedefined windows is to be handled. As can be seen for this example, eachpayment window in column 410 a has a corresponding fee amount in column420 a, and a sub-rule/formula in column 430 a for handling the principalamount. For example, if a payer with a $100 bill wants to make an earlypayment (and inquires at an interface 12 sufficiently in advance of thenominal bill due date), the payment option rules of FIG. 4A lead to apayment option with a $5 fee and a discounted principal amount of$100−2%×$100=$98, or a total of $103. If that same person wants to makean on-time payment, the payment option rules lead to a payment optionwith a $5 fee and the full $100 principal amount due, totaling to $105.A payer who approaches the FI early enough can be offered both the earlypayment option and the on-time payment option, if the payment optionrules specify offering multiple options at one time.

There is also an “other action” field in column 440 a to specify otherfeatures of the payment option rules that define a payment option for agiven window and make it vary from the rule for other windows. Per suchan “other action” payment option rule, an “on-time” payment option mightin some circumstances call for an account credit for the payer's accountfor future purchases from the biller 24 as part of the payment option.In another “other action”, it could also be specified that the billermay waive a late fee accrued that would otherwise be associated withpayment of the bill. See, e.g., the “late over 90 payment” option inFIG. 4A.

In most circumstances the payment option rules will function the samefor all payers falling into a particular payment window of a particularbiller; the option amount offered will differ according to the amount ofthe outstanding bill, but the rule/formula applied will be the same.However, the payment option rule set also may provide an “individualaction” field in column 450 a. This calls for the system (via paymentoption generator 16) to check the data for an individual payer andpermits the system to derive some variation of the payment option rulefor a particular window as applied for a particular payer. This fielddefines the way in which the rule for a window may vary, based onspecific payer data that may be found in the payer account records 34 ormay have to be sought in the accounting system of a biller 24. Forexample, this individual action field might trigger a review of thatparticular payer's billing history to determine the number of paston-time payments made. This could be used for an individual adjustmentof the payment amount otherwise defined by the payment option rule. Itmight also flag the particular payer account record for an action at alater time, such as review of the principal amount shown as due, or anaction solely within the biller system, such as adjustment of a creditlimit established by the biller 24 for that payer.

In case where an “other action” or “individual action” is used toformulate a payment option and a payment occurs based on that option,the payment data sent to the biller 24 need to contain the datanecessary to update the biller's Acct Sys records to reflect the creditor other result of application of the payment option rules that adjuststhe payer account.

FIG. 4B shows an alternate hypothetical set of payment option rules 400b. This may be a second set of rules available for one biller (e.g., asecond set for Biller A) or a rule set for another biller, e.g., BillerB. As can be seen, the hypothetical example of FIG. 4B has fewer paymentwindows defined. The rule set is similar to that in FIG. 4A. However,the rule set of FIG. 4B has a late payment category with a discount onthe entire bill accompanied by an account closing action. Also, the feeand settlement rules on two late payment categories use a percentage ofthe payment amount to define the FI fee rather than a stated dollaramount. FIGS. 4A and 4B are examples, and other rule sets may be definedincorporating other strategies for attracting payment traffic andincreasing collections.

FIG. 6 shows a general schematic diagram for the biller-payer accountdata record 634 of a particular payer. The particular contents of thisrecord provide the data that may be referenced by the payment optionrules when an “individual action” sub-rule appears in the field incolumn 450 a or 450 b. FIG. 6, by way of a hypothetical example offields includes, account no. 610, customer name and contacts 612, FIloyalty program status 614, current billed balance 620, nominal bill duedate 622, detail of current balance 630, payment history 632, settlementoffer history 634, collection analysis recommendation code 636, stopcode 640 and prepay code 642. Various parts of the data in abiller-payer account record 634 may be values that are used in theapplication of a payment option rule when the payment option generator16 is used for a particular payer payment inquiry. Some values arealways used to compute the options and some are used only where the rulehas an “individual action” sub-rule. For example, if the payer recordincludes data showing the person to be an otherwise prompt payingcustomer, application of an individual action sub-rule to such a paymenthistory may result in a payment option more favorable in amount.

The last three fields of FIG. 6 may require explanation, as they providecertain information that may be accessed by the payment option generator16 during the interaction to stage or fulfill a payment option. Thecollection analyst recommendation code 636 is a value resulting fromreview of the account by an analyst (human or automated) as to how theaccount should be handled. The code for the current analysis result isstored here and may correspond to: defer any special action; settle witha discounted amount; accept any payment and write off balance asuncollectible; or another conclusion resulting from the review. The stopcode 640 has to do with situations where a biller may need to determinewhether there are legal or other consequences from accepting a payment.For example, it may need to reject certain late payments on a mortgageto avoid prejudice to its rights. Alternatively, it may need to rejectall payments other than a payment of the exact amount due, or it may beable to accept any payment. The prepay code 642 determines whether aprepayment, i.e., a payment of any amount greater than that due at anygiven date of payment is acceptable. For example, a payer might wish tomake a prepayment on a mortgage in order to save interest, or to prepayan amount expected to be due in the next month, when the payer will betraveling and would not have the ability to initiate another billpayment by the periodic monthly due date. The biller may or may not wishto accept such prepayments, with that position coded here for access bythe payment option generator 16.

Biller Account Management Portal

Referring again also to FIG. 1, the biller account management portal 22may permit a biller 24 to change or modify certain aspects or parametersof the payment rules 36. Such changes or modifications may includeselection of an alternate set of payment option rules or modification ofexisting ones. (Any such changes would have to be acceptable underapplicable laws and regulations.) For example, a retailer may have a setof payment option rules for immediate post holiday payments, to letpayers pay later without severe penalty. For a further example, a biller24 may want to add or adjust a discount amount (e.g., the 2% earlypayment discount in FIG. 4A) or an interest rate (the X% shown in FIG.4A) or the amount of a credit in an “other action” rule used in apayment window. Absent prior agreement (e.g., a promotion reducing theearly payment fee), the fees in column 420 of FIG. 4 will not beadjustable by a biller 24 or the FI unilaterally. However, a properlyconstrained portal 22 and biller account manager 40 may allow a biller24 or the FI to adjust other payment parameters. For example, the biller24 may adjust fees in column 420 within ranges, so long as a minimum feeremains available for allocation to the FI, or the FI may offer apromotional lowered fee or to payers at certain levels of the FI loyaltyprogram (see FIG. 6 at 614), so long as a minimum fee amount remainsavailable for allocation to the biller. (In these cases it is assumedthe fee and settlement rules 38 require that a share of the fee from apayer in column 420 goes to the biller and the FI. If there were nosharing, the party affected may be free to adjust a fee that affectsonly it). Operation of the account biller management portal 22 may alsorequire implementing rules as to the effective time for any changesmade, so that these are transparent and orderly in accordance with theexpectations of the FI and biller 24. For example, a biller 24 mightneed to request a discount change a certain time period in advance ofits use and the system would not implement it until it had been properlynoticed and the time period had passed. All such constraints required bythe FI may be implemented in the software of biller account manager 40and/or account biller management portal 22.

FIG. 7 shows a schematic example of a screen layout 700 for a screen ofthe biller account management portal 22. The screen may be tailored tothe management options available to each biller. In the example, thescreen shows the Available Payment Option Rule Sets 710 and their status712. Set A is shown as selected; set B is shown as available forselection; set C is shown as under development, meaning that it is beingformulated and negotiated by the FI and biller. It will not be availablefor selection until completed, but may, for example, be viewed.

A second part of the screen 700 shows the parameters available foradjustment for the selected payment option rule set 720. As can be seen,a first row 722 identifies the particular rule set, and labels thecurrent value and new value columns. The second through fourth rows 724,726, 728 show the parameters to be adjusted, each with its current valueand an example of a new value that may be specified.

A third part of the screen 700 shows the reports that may be requestedby the biller at the portal 22. Thus, the report request form 730permits the biller user to specify a requested report by: time periodfor the report to cover; the report type, which may be selected from adrop-down menu (not shown); and a requested delivery date.

FIG. 7 is merely an illustrative example. Other screen designs based onprinciples known in the art of graphical user interfaces may be used topermit control by and information exchange with a biller who is usingthe FI system.

Payment Option Generator

When a payer approaches a payer interface 12 to explore or arrange billpayment using the FI third party payment services, there is an exchangeof information at that interface. The interface may be a series ofscreens presented to the payer or an FI agent with whom the payer isinteracting, or the interface may be call center personnel at computerscreens, IVR prompts, smartphone screens or other means of informationexchange used in a user interface 12. The purpose of the exchange is toidentify the payer's payment outstanding, present the payer at least onepayment option and to set up an option as a staged bill paymenttransaction or complete a fulfilled bill payment transaction. Thisinteraction is based on the functions coded into the payment optiongenerator 16 and its interactions with Biller Data 32 and the payerinterface 12.

In FIGS. 5A-5C is a flowchart describing at a high level the activitycentered around the payment option generator 16 in one embodiment. Byway of example of one interface, the flowchart assumes that there is ascreen for displaying information to the payer or to an FI agent who isinteracting with the payer. Generally the same interaction would occurwith a IVR interface or with a call center person working at a computerscreen, but be recast for those interfaces. As seen in FIG. 5A, at 502,the system provides an opening screen allowing the user to select billpayment or fulfillment of a previously staged bill payment. At 504, theinterface accepts a payer selection. If the payer is performingfulfillment, the interface 12 elicits the payment staging number (orinformation that may assist in finding a staged payment record) and goesto step 528; otherwise the system moves to step 506, where the interfaceelicits data for the payment option generator 16: biller identificationby code or guiding the payer to make a selection from biller names, andpayer identification by account no. or name and address or othercontact, such as telephone number, that may help find the correct payeraccount record 34 within information from the biller 24. (In someembodiments, a payer 10 may set up an account or profile with the FIsuch that the payer 10 need not re-enter identification information foreach bill payment.) At 508, a payer account record is sought by query toBiller Data 32; if the biller and payer account information leads to anaccount match in payer account records 34 for the selected biller, thepayment option generator finds the current payment amount (balance due)and identifies the nominal bill due date, e.g., payer account may show$100 due on Aug. 1, 2007. At 510 the interface presents a payment amountand nominal bill due date for payer to confirm; if these are notconfirmed, then the interface terminates the interaction. If the paymentamount and nominal bill due date are confirmed, at 512, the systemprovides these to payment option generator 16.

At 514 the payment option generator 16 software is used to access theapplicable biller's payment option rules among those available 36A, 36B. . . 36N. With these, it determines from the current date and rules theapplicable payment window(s) and formulates payment option(s) Typicallythis will be done by computing the applicable payment window(s) andapplying the corresponding option rule to the payer's current paymentamount due.

At 516, the interface presents at least one of the variable paymentoptions to the payer, including an option based on the payment windowcomputed using the current date as payment date; the interface may alsopresent the computed option for next following payment window. A paymentoption will include a total payment amount and may break out the feeportion and the principal payment portion. The principal payment portionmay be a previously billed amount, a discounted previously billed amountor a previously billed amount adjusted with interest or other late feesthat may not have been billed before but may be part of the paymentoption pursuant to biller payment option rules. For example, with apayer inquiring on a current date of Jul. 10, 2007 and having $100 dueon Aug. 1, 2007, the options presented based on the on-time payment andurgent payment rules in FIG. 4A may include: Option 1: July 10-28 pay$100+$5 fee; Option 2: July 29-30 pay $100+$10 fee.

At 518 the interface elicits payer selection of a presented option,including (in one embodiment) selection with proposed different paymentamount. This may be of interest if the payer does not have the abilityto fund the full amount due or if the payer wishes to make a prepayment.At 520 if no option is accepted, the interface terminates theinteraction; otherwise, the system determines if the accepted option iswith a proposed different payment amount at next step 522. At 522 (FIG.5B), if the payer has proposed a different payment amount than wascalculated for the selected option, then the system goes to step 570(FIG. 5C) to determine if the option with a different payment amount isavailable.

At 572, the system accesses the biller payment option rules 36 and, asneeded, the payer account records 34 to determine if the proposeddifferent payment amount is acceptable. For some billers, it may neverbe acceptable; this is coded into that biller's payment option rules 36.For some billers it may be acceptable, but this may depend on the statusof the individual payer, and whether the payment is less than as definedin the option generated or is more, as with a prepayment. Action maydepend on the values coded into the stop code 640 and the prepay code642 (FIG. 6). At 576, if the proposed, different payment amount is notacceptable, the system terminates the interaction at interface 12. At574 if the different payment amount is acceptable, the payment optiongenerator will revise the generated payment option as first presented tothe payer and go to step 523 to continue.

At step 523 (FIG. 5B), the interface elicits whether the payer is doingonly staging or wants to fund the bill payment and fulfill it now. At524, if the payer selects staging only, the system builds a stagedpayment record, saves the record as staged and terminates interaction atinterface 12. At 526, if the payer selects fulfill now, the systembuilds a staging record and holds it for further steps towardfulfillment, continuing at step 540.

If the payer indicated at step 502 that he/she was fulfilling apreviously staged bill payment, then the payer will also need to reachstep 540, but there are preliminaries. These begin at step 528, whichassumes prior staging and causes the system to find the prior stagingrecord. At 530, if the staging record is found, then the system rerunsoption generator 16 using the current date to find a new payment optionbased on the current date and test the current validity of the option aspreviously staged; if the staged option is no longer valid, then thepayer is sent back to step 510 (FIG. 5A) with a payer account matchalready found. Thus, the system can resume with a new payment optionbased on the current date. At 510 the interface presents a paymentamount and nominal bill due date using the new payment option based onthe current date for payer to confirm; if these are not confirmed, thenthe interface terminates the interaction. At 532 if the staged option isstill valid, the system presents the payer the staged option and elicitsselection for fulfillment; the interface interaction ends if there is noselection; if the option is now selected with a different paymentamount, the system goes to step 570 (FIG. 5C); otherwise it proceeds tostep 540.

At 540, the system has a payer who has elected fulfillment. Accordingly,the system requests a fulfillment payment and then determines if properpayment is provided (cash or other payment form). For example, with anagent assisting the payer, this would be based on the agent confirmingreceipt of the proper amount of cash. At 542 if there is not properpayment, the system terminates interaction at interface 12. If thepayment is proper, at 544 the interface notifies the system offulfillment, and the bill payment staging record is updated to afulfilled payment record. At 546 when payment is received, the systeminitiates execution controller 17 to proceed with the credits andsettlement actions, applying fee and settlement rules. At 550, thesystem issues a message to biller of the account credit amount from thebill payment that was received, net of FI fees and any other agreedadjustments. At 552 the system credits a biller “account” with FI forlater transfer to a biller bank account and finalizes the FI creditearned from handling the bill payment as third party service provider.At 554, the system completes any settlement transfer to biller andinitiates settlement with any fulfillment agent, to complete the actionon this bill payment.

The information provided to the payment option generator 16 in theprocess of FIGS. 5A-5C) may include payer identification information,biller identification, the payer account number to which the payment isto be posted, the proposed payment/transfer amount and a proposedpayment fulfillment date. The payment option generator 16 may generateoptions by computing the difference between the current date (taken asthe proposed payment date) and the nominal bill due date, includingwhether the bill is not yet due or is overdue. If the payment optiongenerator 16 is used in staging, a later proposed payment date may beused instead of the current date. The payer proposes a date based on theexpected fulfillment date. The payment option generator 16 may thengenerate options by computing the difference between the payer's plannedfulfillment payment date and the nominal bill due date. For example, ifthe payer 10 has input a specific date for payment (i.e., the date ofproposed fulfillment), the payment option generator 16 may provide asingle option with fees for payment on that date, the fees beinggenerated based on the amount of time between the proposed fulfillmentpayment and nominal bill due date. Alternatively, if the payer 10 hasnot input a specific date for payment, the payment option generator 16may use the current date to provide a plurality of options, includingpayment window date ranges, amount of fees, and principal payment amountincluding any discount. The fee components are generated based onpayment rules 36 of the biller and the amount of time between variouspossible payment dates and bill payment due date.

Based on the biller's payment option rules 36, the plurality of paymentoptions generated will typically have associated timing windows that thepayment option generator 16 uses. For example, for payment 6-10 daysearly, the payment option may be the bill amount with a first fee amountadded; for payment 2-5 days early, the payment option may be the billamount with a second fee amount added; and for payment 1 day early or onthe bill payment due date, the payment option may be the bill amountwith a third fee amount added. The payment option generator 16 mayfurther apply a payment rule to provide a discount, such as a discountfor early payment. Such discount may be a reduction of the billed amountor the transaction fee. In the case of late fees, the reduction may bein the interest amount or late fee charged, or other the billed amount.The discount may be a percentage or a dollar amount.

Once the payment option generator 16 has generated from payer inputs andpresented to the payer at least one option using the payment optionrules 36A, 36B . . . 36N, the payer 10 is invited to accept or rejectthat option, or if multiple options have been generated, to specify oneoption. The accepted or specified payment option may be staged forpayment. Transaction information from the information provided by thepayer 10 and the accepted or specified payment option informationprovided by the payment option generator 16 may be saved in a stagedpayment record 39. The money transfer to make payment then is consideredstaged and awaiting fulfillment.

The payment option generator 16 may use any stored set of rules todetermine the amount for the payment option, including the variouscomponents that are defined in the payment rules. Thus, each biller mayhave its own set of rules in a biller payment rule set. Further, in someembodiments, a payer 10 may arrange payment of a plurality of bills fromone or more billers 24 during a single staging.

Design of the payment option rules may reflect a variety ofconsiderations. In some instances, a biller 24 may want to encourageearly bill payment. Thus, the fee may decrease, when there is a largerdifference between early payment date and the nominal bill due date. Inmany instances, a biller may want extra payment (compensating for thetime value of money) from a payer who is overdue; thus the payment feemay increase when the payment date is after the nominal bill due dateand/or interest may be charged. Conversely, in some instances, a billermay want to encourage a past due payer to resolve a bill and thus maydecrease the fee when the payment date is after the nominal bill duedate and/or waive late fees associated with late payment. In somesituations, a biller may want to encourage payments from a significantnumber of its customers based on the biller's cash needs or financialcondition. For example, a biller may want to encourage payments beforethe end of a fiscal quarter. At such a time, a more favorable fee and/ordiscount structure might be offered in the range of payment optionsdefined by the applicable payment option rules. The biller 24 mayfurther use other incentive options, such as credits or gift cards, forincentivizing payment. The biller thus may also have flexibility inproviding variable payment options that reflect promotions or react tocompany needs using the present system and method.

In some instances, the FI may want to encourage a payer to use FIservices for bill payment (as opposed to a competitor) and thus mayoffer reduced payment fees. For example, an FI may offer a reducedpayment fee if the payer uses the FI more than one time. Thus, the payermay be prompted at the payer interface 12 to state whether he/she hasused the FI for bill payment in the past. If the payer records indicatethat the payer has used the FI for bill payment in the recent past, orhas achieved a certain FI loyalty program status, the payment fee may bereduced. Further, pursuant to a special arrangement with a biller, theFI may offer a reduced payment fee for all bill payments made to thatparticular biller.

In some instances, a biller may want to incentivize bill payment bywaiving all fees associated with the bill payment, including anyseparate bill fee or payment fee.

In one embodiment, two or more payment options will be offered to thepayer. The number of options displayed may be selected by biller and FI,based on the screen space available and judgments as to the degree ofcomplexity a user can accept. In one embodiment, not more than three maybe displayed. The payment option generator 16 may transmit or specifythe available options to the payer interface 12, where these arepresented for selection by the payer 10. For example, payment optionsoffered sufficiently far in advance of the due date may includeimmediate payment with a lower fee and a discount from the billedamount, as well a payment of a regular fee and no discount for normalpayment a few days ahead of the due date and payment of a higher fee andno discount for urgent payment a within 48 hours of the due date.Similarly, when a payer is already late, the payer may be shown anoption to pay a then-current late charge and also the higher late chargeassociated with the upcoming late payment window, which will apply ifthe payment is made in a few days.

Fee and Settlement Rules

The biller rules 400 a of FIG. 4A may also include the biller-FI feerules in column 460 a that determine how amounts collected are allocatedbetween the FI and each biller 24. Although FIG. 4A states hypotheticalrules, as can be seen, these are subject to agreement between theparties and may define any allocation arrangement that they deemsuitable. As parameters of their relationship, they are coded intospecific values in software modules, data structures and/or objects butadjustable over time as agreed by the parties. Thus, the rules andformulae for allocation shown in FIG. 4A are only an hypotheticalexample. (FIG. 4B shows another example at column 460 b).

At some point after it is confirmed the payer 10 has made the payment,the FI transfers funds, including the principal amount and any biller'sshare of fees, to an account 26 of the biller, effecting completion ofthe money transfer. Completion of the money transfer may besubstantially concurrent with fulfillment by the payer. Alternatively,completion of the money transfer to the biller may be delayed fromfulfillment of the money transfer by a predetermined period, e.g., 2-7days.

There is a time value associated with money. Thus, when the funds paidby the payer 10 are transferred to the biller 24 promptly after the dateof payment by the payer, the time value of the funds inures to thebiller 24. In contrast, when the funds paid by the payer are transferredafter a holding period, at least a portion of the time value of fundsinures to the FI. Determination of when transfer is made to the biller24 may be done pursuant to an agreement between the FI and the biller.This action dictated by this agreement may be implemented in the set ofbiller-FI fee and settlement rules 460 a, as a further set of rules thatspecify how and when the parties' allocated portions of payments will besettled. In some embodiments, payment to the biller 24 may be done foreach payment received from a payee. In another embodiment, aggregatedpayments may be done to a biller for payments made within a certain timeperiod, for example on a daily or weekly basis. Payments to a biller maybe done in any suitable mode, such as through an automated clearinghouse (ACH) credit or by wire or check.

Validation and Fulfillment

It will be seen that large numbers of payment transactions may be madeusing the present system and that funds may be pooled. Accordingly, itis important to have some safeguards against user error that mightresult in payment to the wrong biller. To reduce error, the FI mayrequire a specific biller ID be selected in staging, ensuring that thepayment will go to an entity that is a participant in the system and usethe biller ID to validate information provided by the payer 10 at thepayer interface 12 against biller data 32. Generally, the FI mayvalidate an account number of the payer, a payment amount due, and or apayment due date. The payer may provide the amount due and due date forthe FI to validate. Alternatively, the FI may locate in the billerrecords 32 what seems to be the corrected data and present these to thepayer for confirmation. In some embodiments, validation may besubstantially concurrent with payer's provision of the staginginformation and may be in real time via a connection (not shown) withthe accounting system of a biller 24. (See FIG. 5A at step 508.) In someembodiments, validation may be via a validation file provided by thebiller 24 some time after staging the transaction. Generally, validationis performed during or after staging and before fulfillment of thetransaction.

In one embodiment, the FI/third party service provide receives as payeraccount data to initiate a payment transaction a biller identificationand an account identifier that is an account number. In anotherembodiment, the FI/third party service provide receives a billeridentification and an account identifier that is not an account number,but may be a payer name and address or telephone number. In this case,verification may require some significant searching and matchingalgorithms to help assure that payments go only to the proper payeraccount.

Once a two phase transaction has been staged, the payer 10 uses a payerinterface 12 for a fulfillment payment, initiating fulfillment of themoney transfer. The payer may make a payment by going to an agentterminal, applying money online, or other methods. Fulfillment createswhat in an NBFI money transfer system is called a committed send record.In some instances, a staged transaction may be restaged. For example, iftoo much time has passed between staging of the transaction and expectedfulfillment of the transaction, the payer may be prompted to restage thetransaction to, for example, receive new fee values.

Example—Walk-In Bill Payment

Bill payment may be done as a walk-in payment. In this scenario, a payergoes to a physical FI location to stage and fulfill the money transfer.At the physical location, the payer interacts with an agent or customerservice representative (CSR) and his/her terminal as the payer interface12 of FIG. 1. The CSR thus may enter information from the payer such aspayer identification information, biller identification and the accountto which the payment is to be posted, the proposed payment/send amount,and a proposed payment date. The CSR validates the information receivedfrom the payer. Such validation may be real time via atelecommunications link, for example via web or phone, with the billerdata 32. Generally, validation may be done by using an account numberprovided by the payer to look up a due date on a validation file fromthe biller data 32.

The CSR inputs the information and the information is transmitted to thecentral data processor 14 and used by the payment option generator 16 toformulate and display payment options for the payer. The payment optionsmay be generated based on the difference between the payment date andthe bill payment due date or may be generated based on otherconsiderations by the biller or the FI. The payer selects one of theoffered payment options. The CSR then creates a bill payment stagingrecord based on the information provided by the payer and the paymentoption selected by the payer. The payer then or later submits payment,typically at an agent location, effecting fulfillment of the moneytransfer. The CSR then creates a committed bill payment transactionrecord. The FI provides a receipt to the payer.

The FI transfers funds, including the principal payment amount and anyshared portion of fees to the biller. Such transfer may be substantiallyconcurrent with the payment by the payer or may be delayed from paymentby the payer.

Example—Electronic Payment

Bill payment may be done as an electronic or on-line bill paymenttransaction. In this scenario, a payer logs onto a website of an FI or abiller linked to an FI website to stage and optionally fulfill the moneytransfer. The user enters information to the website via a browser,including, for example, payer identification information, billeridentification and the account to which the payment is to be posted, theproposed payment/send amount, the bill payment due date, and a proposedpayment date. The information from the payer is validated. Suchvalidation may be real time via a telecommunications link, for examplevia web or phone, with the biller date 32. Generally, validation may bedone by using an account number provided by the payer to look up a duedate on a validation file from the biller data 32.

The input information is transmitted to the central data processor 14and used by the payment option generator 16 to formulate and displaypayment options for the payer 10. The payment options may be generatedbased on the difference between the payment date and the bill paymentdue date or may be generated based on other considerations by the billeror the FI. The payment options are transmitted to the payer and thepayer selects one of the payment options. A bill payment send stagingrecord is created based on the information provided by the payer and thepayment option selected by the payer.

The payer may select to submit payment online from a bank accountavailable on-line, via credit or debit card, etc., effecting fulfillmentof the money transfer. A committed bill payment send transaction recordis created. The FI provides a receipt to the payer on-line or via email,SMS, or other communication mode.

The FI transfers funds, including the principal payment amount and thebill fee to the biller. Such transfer may be substantially concurrentwith the payment by the payer or may be delayed from payment by thepayer.

Although the present invention has been described with reference topreferred embodiments, persons skilled in the art will recognize thatchanges may be made in form and detail without departing from the spiritand scope of the invention.

We claim:
 1. A system comprising: a computer system comprising a dataprocessor with a payment option generator and payment executioncontroller, the computer system configured for accessing a storagedatabase with payment option rules and biller data from a plurality ofbillers, the biller data including payer account records for a payer inrelation to a selected one of the plurality of billers, the biller datafor the payer comprising at least one account identifier, a paymentamount due, and a nominal bill due date; wherein one or more of thepayment option rules is associated with each of the plurality ofbillers, the payment option rules defining variable payment options forthe associated billers, at least one of the payment options for definingthe payment amount due based in part on a difference between a proposedpayment date and the nominal bill due date; the data processor incommunication with a rules management portal for access to parameters ofthe payment option rules, including parameters for the payment amountdue, the payment option generator configured for accessing the one ormore payment option rules associated with the selected biller anddeveloping at least one payment option for the payer based on one ormore of the payment option rules associated with the selected biller,wherein the at least one payment option comprises the payment amount duebased in part on the difference between the proposed payment date andthe nominal bill due date; the data processor in communication with apayer interface for staging a money transfer to make payment to theselected biller, the payer interface configured for presenting the atleast one payment option to the payer and for accepting a payment optionselection and a payment funding confirmation for the payment amount dueand payment date, wherein the computer system builds a staging recordbased on the payment option selection; wherein the variable paymentoptions are available for the payer to pay early relative to the nominalbill due date and to pay later relative to the nominal bill due date andthe payment amount due is validated responsive to the proposed paymentdate; and the payment execution controller responsive to the paymentoption selection and the payment funding confirmation for receiving thepayment amount due, wherein the bill payment staging record is updatedto a fulfilled payment record, the payment execution controllerconfigured for applying fee and settlement rules established between thepayer and a provider of bill payment services and initiating the moneytransfer to make payment to the selected biller on behalf of the payer.2. The system of claim 1, wherein the payment amount due decreases ifthe proposed payment date is earlier than the nominal bill due date. 3.The system of claim 1, wherein a discount is applied to the paymentamount due when the proposed payment date is within a predeterminedtiming window associated with a payment option for early payment.
 4. Thesystem of claim 1, wherein: the payment option generator determines thedifference between the proposed payment date and the nominal bill duedate; and when the proposed payment date is after the nominal bill duedate, a payment option generated waives a late fee.
 5. The system ofclaim 1, wherein the payer interface is provided on a website.
 6. Thesystem of claim 5, wherein the money transfer is fulfilled to make thepayment to the selected biller in response to payer identificationinformation entered at the website.
 7. The system of claim 5, whereinthe data processor is further configured for: receiving from the payerat the website information including at least a biller identification ofthe selected biller, a proposed payment amount, the proposed paymentdate, and the nominal bill due date; verifying at least a portion of thereceived information against payer account records; calculating thedifference between the proposed payment date and the nominal bill duedate; and presenting to the payer the at least one payment option,wherein the payment amount due is responsive to the calculateddifference between the proposed payment date and the nominal bill duedate and the payment option rules associated with the selected biller.8. The system of claim 7, further configured for receiving a selectionof the at least one payment option from the payer at the website.
 9. Thesystem of claim 8, further configured for determining that properpayment is provided based on confirming receipt of a payment from thepayer to fund the selected payment option.
 10. The system of claim 9,further configured for crediting the payment to the selected biller, thecredited payment comprising a share of fees computed based on theestablished fee and settlement rules.
 11. The system of claim 10,further configured for delivering the payment to the selected biller ata time separate from receiving payment from the payer as determined bythe established fee and settlement rules.
 12. The system of claim 1,further configured for notifying the selected biller of the payment at atime substantially commensurate with receiving payment from the payer.13. The system of claim 1, wherein the user interface is accessible viaa payer computer.
 14. The system of claim 1, wherein the user interfaceis provided on a mobile phone or mobile platform.
 15. A method forpayment services comprising: with a computer system comprising a dataprocessor with a payment option generator and payment executioncontroller, accessing a storage database with payment option rules andbiller data from a plurality of billers, the biller data including payeraccount records for a payer in relation to a selected one of theplurality of billers, the biller data for the payer comprising at leastone account identifier, a payment amount due, and a nominal bill duedate; wherein one or more payment option rules is associated with eachof the plurality of billers, the payment option rules defining variablepayment options for the associated billers, at least one of the paymentoptions for defining the payment amount due based in part on adifference between a proposed payment date and the nominal bill duedate; communicating between the computer system and a rules managementportal for access to parameters of the payment option rules, includingparameters for the payment amount due; with the data processor,accessing the one or more payment option rules associated with theselected biller and developing at least one payment option based on oneor more of the payment option rules associated with the selected biller,wherein the at least one payment option comprises a payment amount duebased in part on the difference between the proposed payment date andthe nominal bill due date; and staging a money transfer to make paymentto the selected biller in communication with a user interface configuredfor presenting the at least one payment option and for accepting apayment option selection and a payment funding confirmation for thepayment amount due and payment date; with the computer system, buildinga bill payment staging record based on the payment option selection,wherein the variable payment options are available to pay early relativeto the nominal bill due date and to pay later relative to the nominalbill due date and the payment amount due is responsive to the differencebetween the proposed payment date and the nominal bill due date;responsive to the payment option selection and the payment fundingconfirmation for receiving the payment amount due, updating the billpayment staging record to a fulfilled payment record; applying fee andsettlement rules established between the payer and a provider of billpayment services; and initiating the money transfer to make payment tothe selected biller on behalf of the payer.
 16. The method of claim 15,wherein the user interface is provided on a website.
 17. The method ofclaim 15, wherein the user interface is provided on a mobile platform.18. The method of claim 15, wherein the user interface is provided on amobile phone.
 19. The method of claim 15, wherein the payment amount duedecreases if the proposed payment date is earlier than the nominal billdue date.
 20. The method of claim 15, wherein: the payment optiongenerator determines the difference between the proposed payment dateand the nominal bill due date; and a discount is applied to the paymentamount due when the proposed payment date is within a predeterminedtiming window associated with a payment option for early payment. 21.The method of claim 15, wherein: the payment option generator determinesthe difference between the proposed payment date and the nominal billdue date; and when the proposed payment date is after the nominal billdue date, a payment option generated waives a late fee.